Method for authenticating and verifying sms communications

ABSTRACT

A method for operating a first computational device to facilitate the secure transfer of a message between the first computation device and a second computational device is described. The method comprises operating the first computational device according to the following steps: forming an encrypted message from the message on the basis of a key derived from one or more codes associated with the second computational device; transmitting the encrypted message to the second computational device; purging the message and the encrypted message from the first computational device; receiving the encrypted message and said one or more codes from the second computational device; upon decrypting the message on the basis of the one or more codes transmitting the decrypted message to the second computational device.

FIELD OF THE INVENTION

The present invention is concerned with a method for facilitating securetransactions over a wireless medium. In particular the invention isconcerned with a method for authenticating and verifying text messagessent to wireless devices such as cell phones.

BACKGROUND TO THE INVENTION

Over the past decade the use and penetration of computational devicessuch as mobile or cellular phones and related technology, such as PDA's(personal digital assistants) has increased dramatically. Apart fromproviding voice communications, modem cell phones support SMS (shortmessage services) by which a message of up to 160 characters of text maybe entered, by means of a sender phone's keypad, or by a PC keyboard viathe Internet, and transmitted over a telephone network for display on areceiver phone's display screen.

Various services associated with SMS have developed. According to one ofthese services text messages, with an associated addressee's cell phonenumber, may be sent from a content sender such as an Internet connectedpersonal computer to an SMS web-server. The SMS web-server provides agateway to a telephone network in order to deliver the message to theaddressed cell phone where it is displayed in standard SMS format.

Although there have been no reported cases of successful interception ofSMS messages via the SMS protocol under the GSM specifications, the useof SMS for transmitting sensitive information, such as financialtransaction data, has been limited due to a perception that SMStransactions are potentially insecure. There have been solutionsproposed for secure mobile banking that involve the use of a SIM toolkitwhereby templates and security procedures are handled by modifying acell phone user's SIM card. However, permission and agreement must beobtained from each carrier's SIM card provider. In order for a user tomake use of a particular financial institution's SMS banking facilitythe user must purchase a SIM card from a provider with whom thefinancial institution has an agreement.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided amethod for operating a first computational means to facilitate thesecure transfer of a message between the first computational means and asecond computational means, the method comprising operating the firstcomputational means according to the following steps:

forming an encrypted message from the message on the basis of a keyderived from one or more codes associated with the second computationaldevice;

transmitting the encrypted message to the second computational device;

purging the message and the encrypted message from the firstcomputational device;

receiving the encrypted message and said one or more codes from thesecond computational device;

upon decrypting the message on the basis of the one or more codestransmitting the decrypted message to the second computational device.

In a preferred embodiment the first computational means comprises acomputer network server in communication with a cellular telephonenetwork. The computer network in question may be the Internet. Themessage may originate at a content sender in the form of a personalcomputer connected to the first computational device by means of anetwork such as the internet.

Alternatively, the first computational means may comprise a cellularphone.

It is envisaged that the second computational device will usually be acellular phone and that the message will be delivered to the cellularphone in SMS format.

The step of forming an encrypted message will normally involve formingthe key on the basis of the cellular phone's phone number and a personalidentification number to be used by the owner of the cellular phone.

In a preferred embodiment the step of transmitting the encrypted messageto the cellular phone includes transmitting a message identifier that isassociated with the encrypted message.

Preferably the cellular phone transmits both the encrypted message andthe message identifier back to the first computational means.

The method may further include the step of the computational meansgenerating an error code if the message identifier is not received backfrom the cellular phone within a predetermined time period.

In a preferred embodiment the one or more codes comprise a PIN and CLIassociated with the cellular phone.

The first computational means may check the PIN and CLI for consistencyin length and/or field type.

Preferably the method further includes the step of sending an errorstatus message to the content sender advising of any error conditions.

Where two-way authentication between the first computational device andthe second computational device is required, the method may include astep of encrypting the message with a private key of the firstcomputational means and a public key of the second computational means

The method may be used to conduct financial transactions between afinancial institution and a client of said institution where the clientoperates the cellular phone and the institution operates the computernetwork server.

According to a further aspect of the invention there is provided acomputer software product, provided upon a computer readable medium, forexecution by a computational device, the computer readable mediumincluding instructions for:

forming an encrypted message from a message on the basis of a key;

transmitting the encrypted message to a second computational device;

purging the message and the encrypted message;

receiving the encrypted message and said one or more codes from thesecond computational device;

upon decrypting the message on the basis of the one or more codestransmitting the decrypted message to the second computational device.

Other preferred features of the invention will be apparent from thefollowing detailed description which will make reference to a number offigures as follows.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the entities involved during theperformance of a secure messaging method according to a preferredembodiment of the invention.

FIG. 2 includes the entities of FIG. 1 and additionally shows messagesthat are transferred between the depicted entities during the securemessaging method.

FIG. 3 is a flowchart of a method of operation of a secure serverhandling messages outgoing to receiver according to a preferredembodiment of the invention.

FIG. 4 is a flowchart of a method of operation of a secure serverhandling messages incoming from a receiver according to a preferredembodiment of the invention.

FIG. 5 schematically depicts an application of a secure messaging methodaccording to an embodiment of the present invention.

FIG. 6 depicts the steps involved in a fund transfer operation accordingto an embodiment of the present invention.

FIG. 7 depicts the steps involved in a B-Pay operation according to anembodiment of the present invention.

FIG. 8 depicts the steps involved in a balance inquiry operationaccording to an embodiment of the present invention.

FIG. 9 depicts the parties involved in a transaction according to afurther embodiment of the present invention.

FIG. 10 depicts the steps involved in a transaction according to afurther embodiment of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

FIG. 1 illustrates the entities involved in a secure SMS transactionaccording to a preferred embodiment of the present invention. Contentsender 2 will typically be client workstation, for example a personalcomputer, at which a message to be sent to receiver 6 originates.Security server 4 is a web-server in communication with the contentsender. The security server executes a software product that containsinstructions for executing a method according to an embodiment of thepresent invention. The security server is able to establishcommunications with receiver 6 which is typically an SMS capable cellphone. The communication between content sender 2 and security server 4may be by means of an SSL (secure socket layer) Internet connection, forexample. Security server 4 provides a gateway between the content senderand a cell phone telephone network to which receiver 6 is a subscriber.It will be realised that the functionality of security server 4 may beintegrated into content sender 2. Furthermore, the content sender 2could comprise a cell phone. Accordingly, in other embodiments thepresent invention may be used to facilitate secure messaging directlybetween two computational devices comprising cell phones.

A secure communication method according to a preferred embodiment of thepresent invention will now be explained with reference to FIGS. 2, 3 and4. Initially, at box 18 of FIG. 3, security server 4 awaits an incomingdata package 8 from content sender 2. Data packet 8 contains a messagefor receiver 6 along with the receiver's PIN number and telephone numberor line identifier (CLI). By pre-arrangement the PIN number is known toboth content sender 2 and receiver 6 at the time that the owner ofreceiver 6 subscribes to the secure transaction service. At the time ofsubscribing the phone number of receiver 6 is also provided to contentsender 2.

At box 20 (FIG. 3) security server 4 assigns a unique message identifier(MID) to the received data packet. At box 22 the message identifier isstored in memory of security server 4. At box 24 the receiver's phonenumber (CLI) and PIN are retrieved from data package 8.

At box 26 the security server generates an encryption key from the PINand CLI according to a standard algorithm. If two-way authentication isrequired a PKI (public key infrastructure) technique may be employed bywhich the message is encrypted with the private key of the sender andthe public key of the receiver.

Several cryptography techniques are known and are described in AppliedCryptography, Second Edition: protocols, algorithms, and source code inC, ISBN 0-471-11709-9, John Wiley & Sons, USA, 1996 by Bruce Scheiner.

At box 28 the message is encrypted using the encryption key to producean encrypted message Enc{Msg}. At box 30 the encrypted message andunique message identifier, MID, are packaged to form a data package 10.Data package 10 also includes a text message, which is displayed onreceiver 6 as a request to enter the user PIN. Data package 10 istransmitted to receiver 6 at box 32. The security server then, at box34, purges itself of information from data packet 8, including themessage, PIN code, phone number, key and encrypted data. At the sametime a clock is started that records the time at which a message withthe unique message identifier allocated in box 22 was transmitted. TheMID is stored on server 4, along with a timeout value for future use aswill be explained shortly.

It will be noted that because no copy of the message, either plain orencrypted, is stored on secure server 4 after the message is dispatchedto the receiver 6, the likelihood of a hacker successfully obtaining themessage from the secure server is greatly reduced. Most financialinstitutions require that no sensitive information is saved on theserver. The message is encrypted and sent to the receiver so that onlythe receiver who knows the PIN and has the right cell phone SIM canretrieve the clear message. If somebody without the PIN picks up thereceivers cell phone, he/she will only see a gibberish encryptedmessage. The receiver needs to send the encrypted message back withhis/her pin from his/her SIM, so that the message can be successfullydecrypted.

Upon receiver 6 receiving data package 10 a text message requesting aPIN be entered is displayed. The user of receiver 6 then repliesentering the PIN. Data package 12 is then transmitted back to securityserver 4. Data package 12 contains the receiver's phone number (CLI),PIN and the information which was in data package 10 being the messageidentifier (MID) and the encrypted message Enc{Msg}.

At box 38 (FIG. 4) security server 4 receives data package 12 fromreceiver 6.

The security server obtains the message identifier MID and CLI from thedata package and checks to see if the timeout value for that messageidentifier has been exceeded at box 40. If the timer has indeed timedout then control diverts to box 41 where an error message is transmittedto the content server. The message ID and user phone number areextracted from the incoming data package at boxes 42 and 46.

At box 44 the message ID is checked to see if it is valid. At box 48 theuser's PIN code is extracted from the incoming data package. At box 50 acheck is undertaken to ensure that the PIN and receiver phone number(CLI) are correct. At box 52 a key is generated from the receivers phonenumber and PIN. At box 54 the key is used to decrypt the encryptedmessage Enc{Msg}. At box 60 the decrypted message, item 14 of FIG. 2, issent to receiver 6 using the receiver's phone number. At box 62 a statusmessage along with the message identifier (MID) 16, (FIG. 2) is sent tothe content sender 2. The status message comprises an error code thatreflects whether or not the authentication and verification processterminated successfully. The error code may indicate if the messageidentifier received back from receiver 6 was invalid, if the PIN and/orCLI from the receiver were invalid or if the decryption of Enc{Msg} fromthe receiver was unsuccessful. If no errors were encountered then theerror message will indicate that the procedure was successful.

At box 64 the security server purges from its memory the user PIN,receiver phone number, encryption key and the decrypted message.

A software product executable by security server 4 for implementation ofthe above method will preferably include instructions for

forming an encrypted message from the message from sender 2 on the basisof a key;

transmitting the encrypted message to a second computational device,such as receiver 6;

purging the message and the encrypted message;

receiving the encrypted message and one or more codes from the secondcomputational device; and

upon decrypting the message on the basis of the one or more codestransmitting the decrypted message to the second computational device

An example of the use of the authentication and verification methoddescribed with reference to FIGS. 1-4 will now be explained withreference to FIG. 5 wherein the same indicia as employed in FIG. 2 areused to identify similar items. A stockbroker 70, on completion of astock transaction deal for a customer having a receiver 6 (i.e. a cellphone), generates a message by means of content sender (personalcomputer) 2. The message is encrypted and sent to the customer's cellphone 6. The customer enters a PIN into receiver 6 which, along with theencrypted message and the customer's phone number (CLI) is sent back tosecure server 4. This is normally done by using the “Reply” functionthat is available on most cell phones. The secure server receives theresponse from the receiver 6 and decrypts the message using the CLI andPIN to generate the decryption key.

The decrypted message is then sent back to the receiver and a statusmessage is sent to the content sender 2 either confirming that themessage was successfully delivered or providing an error code if messagedelivery failed.

FIG. 6 is a flowchart of the interaction between a cell phone user 6 andthe web-server 4 of a financial institution. Initially, at box 72 thecell phone user initiates a funds transfer by sending an SMS message,optionally with username, to secure web-server 4.

The web-server verifies the user using the cell phone's CLI and theusername that is in the message. Web-server 4 responds with an SMS menuhaving a number of options. For example the options may be to make abalance inquiry or to make a funds transfer or a to make a payment. Atbox 76 the user receives the menu message and replies by selecting thedesired option. For example user 6 may decide to make a funds transfer.

At box 78 the secure web-server 4 verifies the user using the CLI andsends an appropriate response depending on which menu item the userselected at box 76. For example the secure web-server may send a requestfor user 6 to confirm on which of its accounts the funds transfer is tobe performed. At box 80 the user enters any data necessary for thetransfer to continue into cell phone 6. The data may be the amount to betransferred and identification of the account from which the amount isto be transferred and the destination account. At box 82 secureweb-server 4 once again verifies the user on the basis of the cellphone's CLI. An encrypted SMS message is sent confirming that the fundstransfer is ready to proceed. Also sent is a non-encrypted messagerequesting the user to enter a PIN. At box 84 the user receives therequest for PIN and returns the PIN and the encrypted message. At box 86the server verifies the user using the cell phone's CLI, PIN and receiptof the encrypted message. Once verified, confirmation of the requestedtransaction is sent back to user 6 and displayed at box 87 on the user'scell phone. For example a message such as “You have transferred <amount>from <Account No. 1> to <Account No. 2>.” may be sent.

FIG. 7 is a flowchart of the exchange of information between the user ofa cell phone 6 and the secure web-server 4 of a financial institution inorder to make a B-Pay transaction. Initially, at box 88 the cell phoneuser initiates a B-Pay transaction by sending an appropriate SMSmessage, with username, to secure web-server 4. At box 90 the web-serververifies the user by means of the cell phone's CLI and the username thatis in the message. Web-server 4 responds with an SMS menu having anumber of options including a B-Pay transaction option and, for example,a balance option and a fund transfer option. At box 92 the user receivesthe menu message and replies by selecting the B-Pay transaction option.At box 94 secure web-server 4 verifies the user using the CLI and sendsan appropriate response for example a query as to which account theB-Pay transaction amount should come from.

At box 96 user 6 enters the account to be debited for the transactionand the B-Pay payee's code. At box 98 secure web-server 4 once againverifies the user on the basis of the cell phone's CLI. An encrypted SMSmessage is sent to the user's cell-phone confirming that the fundstransfer is ready to proceed and requesting the user to enter a PIN inthe event that a transaction request has been confirmed. At box 100 theuser receives the request for PIN and enters the pin number into cellphone 6 and transmits it web-server 4. A message including the PINnumber and the encrypted message is returned to web-server 4.

At box 102 the server verifies the user using the cell phone's CLI, PINand the receipt of the encrypted message. Once verified confirmationthat the requested transaction is completed is sent back to the cellphone. At box 103 the cell phone displays the confirmation message.

FIG. 8 is a flowchart of the exchange of information between the user ofa cell phone 6 and the secure web-server 4 of a financial institution inorder to make a balance inquiry. Initially, at box 110 the cell phoneuser initiates a balance inquiry by sending an appropriate SMS message,with username, to secure web-server 4. At box 112 the web-serververifies the user by means of the cell phone's CLI and the username thatis in the message. Web-server 4 responds with an SMS menu having anumber of options including a balance inquiry option. Other options onthe menu might be, for example an option to make a transfer of funds andan option to make a B-pay payment.

At box 114 the user receives the menu message and replies by selectingthe balance inquiry option. At box 116 the secure web-server 4 verifiesthe user using the CLI and sends an appropriate response for example aquery as to which of the user's accounts the balance inquiry should bein respect of. At box 118 the user selects the account to be queried. Atbox 120 secure web-server 4 once again verifies the user on the basis ofthe cell phone's CLI. An encrypted SMS message confirming that therequested balance is to be made available is sent back to the user alongwith a request that the user to enter his/her PIN. At box 122 the userreceives the encrypted message and the request for PIN. The user entersthe PIN into cell phone 6 and sends the PIN and the encrypted messageback to the web server. At box 124 the server verifies the user usingthe cell phone's CLI and PIN and returned encrypted message. Onceverified a non-encrypted message stating the account balance for theaccount in question is sent back to the user's cell phone 6 for displayon the cell phone at box 125.

A further embodiment of the present invention will now be described withreference to an example depicted in FIG. 9. In FIG. 9 a party X 152,instructs his bank's server, host X 154, to transfer funds to party Y'saccount, where host Y is a server of party Y's bank.

The steps in the exemplary method are illustrated in FIG. 10 and are asfollows:

-   1. Party X sends a message to host Y for forwarding to Party Y. For    example the message might be “Transfer $100 to Party Y's account at    Some Bank.” In this scenario party X intends to transfer funds to an    account of Party Y's at Some Bank.-   2. Host X then requests the public key of party Y from a local or an    external repository 156, (the repository could be a database in    Host Y) and then encrypts the message from party X.-   3. Host X then generates a unique random message ID (MID), encrypts    this ID with party X's public key, and sends it back to party X.-   4. Party X replies with his PIN. This verifies that X's PIN has not    been compromised, assuming he is still in possession of his SIM.-   5. Host X unlocks party X's private key (asynchronous keys) with the    given PIN, and then decrypts the MID with the private key. If the    MID does not match the one stored on Host X, then the transaction is    logged as fraudulent.-   6. Host X again uses party X's private key (still temporarily    unlocked), this time to encrypt a one-way hash of the encrypted    message created in Step 2. this is the equivalent of a digital    signature—proving that party X was the originator of the message.    This signature is appended to the encrypted message from Step 2.-   7. The encrypted message and digital signature are sent to Host Y    over a secure trusted channel 164. For example the message may be    sent in HTTPS format or it could be by dedicated (wired) links to a    private telecommunications network or virtual private network over    Internet.-   8. Upon Host Y receiving an encrypted message from Host X, it    requests the public key of Party X from the public key database 156    and decrypts the digital signature. The encrypted message is then    hashed and the two hashes are compared. The comparison is performed    to verify the originator of the message (party X) and to ensure that    the message has not been tampered with.-   9. The encrypted section of the message (i.e. the message from Party    X that has been encrypted with Y's public key) is sent to Y along    with a note of the source of the message X.-   10. Party Y then returns the message, with his private PIN.-   11. Party Y's private key is unlocked with the given PIN, and the    message is then decrypted.-   12. If the message is decrypted successfully, it is sent to Y, and    notification is sent to Host X, which in turn informs Party X of the    successful decryptions.

It will be realised that from party Y's perspective the above-describedtransaction method provides a number of advantages.

Confidentiality—because the message is encrypted with party Y's publickey, only party Y can decrypt the message, using his private key.

Authentication—successful decryption of the message using party X'spublic key implies it could only have been encrypted in the first placeusing party X's private key.

Data Integrity—party Y may be confident that the message from party Xhad not been tampered with en-route.

Non-repudiation—party X cannot subsequently deny having sent neither themessage, nor dispute message content for the following reasons. Firstly,any entity could have encrypted a message with party Y's public key fortransmission to Y, but that entity would not have access to party X'sprivate key with which to encrypt the hash.

Secondly, the hash is unique to a particular message—allegedly differentcontent would have produced hashed output different to that received andsuccessfully decrypted.

From party X's perspective the transaction method provides a number ofadvantages as follows:

Confidentiality—message encrypted with party Y's public key can only bedecrypted using party Y's private key.

Authentication—encrypted message could only have been decrypted usingparty Y's private key.

Data Integrity—party X may be confident that his message to Y has notbeen tampered with en-route.

Non-repudiation—party Y cannot subsequently deny having received themessage for the following reasons: Firstly, only party Y could havedecrypted the main message segment using party Y's private key beforeapplying hashing to derive the hash for reconciliation. Secondly, thehash is unique to a particular message—allegedly different content wouldhave caused the reconciliation to fail.

In the scenario of FIGS. 9 and 10, private keys are stored in anencrypted form, i.e. a synchronous form, on the server. The only way toaccess such keys is to unlock them with a key supplied by the end user.It will be readily apparent that the method may be readily extended toallow users to host their own private keys on their phones or otherdevices.

Methods according to embodiments of the present invention may be readilyadapted to other financial transactions between a remote cell phone userand a server of a financial institution. For example the system may alsobe used to make credit card payments. Furthermore, encrypted messagesmay be sent inside multi-media messaging service (MMS) pictures. Forexample, the message may be embedded inside an image according tosteganography techniques. In this way, an image of a person can be usedto verify an identity, while at the same time, embedded content in theimage can be used to transmit information. That is, the originator ofthe message is both visually and electronically identified.

Although the present invention has been described in terms of preferredembodiments, it is not intended that the invention be limited to theseembodiments. Equivalent methods, structures, arrangements, processes,steps and other modifications apparent to those skilled in the art willfall within the scope of the following claims.

1. A method for operating a first computational device to facilitate thesecure transfer of a message between the first computational device anda second computational device, the method comprising operating the firstcomputational device according to the following steps: forming anencrypted message from the message on the basis of a key derived fromone or more codes associated with the second computational device;transmitting the encrypted message to the second computational device;purging the message and the encrypted message from the firstcomputational device; receiving the encrypted message and said one ormore codes from the second computational device; upon decrypting themessage on the basis of the one or more codes transmitting the decryptedmessage to the second computational device.
 2. A method according toclaim 1, wherein the first computational means comprises a computernetwork server in communication with a cellular telephone network.
 3. Amethod according to claim 1, wherein the computer network is theInternet.
 4. A method according to claim 1, wherein the messageoriginates at a content sender in the form of a personal computerconnected to the first computational device by means of a network.
 5. Amethod according to claim 1, wherein, the first computational means maycomprises a cellular phone or a wireless personal digital assistant. 6.A method according to claim 1, wherein the second computational devicecomprises a cellular phone.
 7. A method according to claim 1, whereinthe step of forming an encrypted message involves forming the key on thebasis of the cellular phone's phone number and a personal identificationnumber to be used by the owner of the cellular phone.
 8. A methodaccording to claim 7, wherein the step of transmitting the encryptedmessage to the cellular phone includes transmitting a message identifierthat is associated with the encrypted message.
 9. A method according toclaim 8, wherein the cellular phone transmits both the encrypted messageand the message identifier back to the first computational means.
 10. Amethod according to claim 8, further including the step of thecomputational means generating an error code if the message identifieris not received back from the cellular phone within a predetermined timeperiod.
 11. A method according to claim 7 wherein the one or more codesinclude a PIN and CLI associated with the cellular phone.
 12. A methodaccording to claim 11, wherein the first computational means checks thePIN and CLI for consistency in length and/or field type.
 13. A methodaccording to claim 1, further including the step of sending an errorstatus message to the content sender advising of any error conditions.14. A method according to claim 1 wherein two-way authentication betweenthe first computational device and the second computational device isprovided, the method further including a step of encrypting the messagewith a private key of the first computational means and a public key ofthe second computational means.
 15. A computer software product,provided upon a computer readable medium, for execution by acomputational device, the computer readable medium includinginstructions for: forming an encrypted message from a message on thebasis of a key; transmitting the encrypted message to a secondcomputational device; purging the message and the encrypted message;receiving the encrypted message and one or more codes from the secondcomputational device; upon decrypting the message on the basis of theone or more codes transmitting the decrypted message to the secondcomputational device.